Security for gaming devices

ABSTRACT

A secure smart card or other secure modular memory device is plugged into (or otherwise connected to) a port of a game controller board internal to a gaming machine. The smart card is programmed to detect an encrypted “challenge” message from the host CPU and output an encrypted “response.” If the host CPU determines that the response has the expected properties, then the host CPU verifies that the game program is authentic (i.e., the game program is accurate and authorized for use by that particular gaming machine and customer), and the game can be played. The challenge/request exchange may be performed before every game is played on the machine or at any other time. If the response is improper, then the host CPU will issue a halt command to halt play of the game. By controlling access to the properly programmed smart card, gaming machines cannot run unauthorized copies of the game program. Various other security features are disclosed for protecting communications and data within the gaming machine, such as erasing secure memories if tampering is detected and requiring that an authorized secure smart card be connected to each one of multiple game boards in a single gaming machine for accurate secure communications between boards.

FIELD OF THE INVENTION

This invention relates to gaming devices, such as slot machines, and inparticular to techniques to ensure the authenticity of the gamingsoftware used in such devices.

BACKGROUND

Modem gaming machines, such as slot machines, are software controlled.For example, the final symbols displayed by motor driven reels arepredetermined using a programmed microprocessor. Video gaming machinesare totally controlled by a processor running a game program. As thegames become more complex, such as incorporating special bonus games,the software becomes more complex and more expensive to develop.

It is important to implement security provisions to prevent copying ofthe game program and prevent unauthorized changes to the game program.

In some cases, an unscrupulous competitor may obtain a gaming machineand copy the object code using sophisticated reverse engineeringtechniques. The copied code may then be loaded into a generic platformgaming machine, which is then sold in various countries that offerlittle enforcement of copyrights. I other cases, the code may beillegally changed to alter the chances of winning.

Accordingly, what is needed is an ultra-high security technique thatprevents a legitimate gaming application from being illegally changed orillegally copied and used in an unauthorized machine. Also what isneeded is a technique that prevents any access to secret software in thegaming machine.

SUMMARY

In one embodiment of the invention, a secure smart card or other securemodular memory device is plugged into (or otherwise connected to) a portof a game controller board internal to a gaming machine. The gamecontroller board contains the main CPU, memory, and other circuitry foroperating the gaming machine. The game program may be stored in a massstorage device, such as a CD ROM/reader, hard disc, or flash device, andconnected to the game controller board via an I/O port. The plug-inmodule will be referred to herein as a dongle. The dongle is programmedto detect an encrypted “challenge” message from the host CPU and outputan encrypted dongle “response.” If the host CPU determines that theresponse has the expected properties, then the host CPU verifies thatthe game program is authentic (i.e., the game program is accurate andauthorized for use by that particular gaming machine and customer), andthe game can be played. The challenge/response exchange may be performedbefore every game is played on the machine or at any other time.

If the dongle response is improper, then the host CPU will issue a haltcommand to halt play of the game.

The dongle is designed in such a way that its software cannot be copied.Existing smart card designs, standards, and encryption providesufficient security. Since the smart card software cannot be copied, andencryption is used, there is no way to determine the proper dongleresponse to a particular challenge by the host CPU. So, even if the gameapplication were successfully copied, without the associated securedongle the game could not be performed.

Methods for handling (e.g., distributing and allocating) the dongles arealso described to allow the manufacturer to control the post-sale usesof the gaming machines.

In a further step to achieve added security, the game controller boardhas a secure area, where any attempt to gain access to the circuitryresults in the software being erased. Other security features are alsodisclosed, such as requiring that an authorized secure smart card beconnected to each one of multiple game boards in a single gaming machinefor accurate secure communications between boards.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a perspective view of a gaming machine that contains the gamecontroller board and secure dongle in accordance with one embodiment ofthe invention.

FIG. 2 illustrates the basic functional units in the gaming machine ofFIG. 1.

FIG. 3 is a front view of a conventional smart card performingencryption/decryption and outputting a particular response after achallenge is transmitted by the host CPU.

FIG. 4 is a flowchart of one embodiment of the gaming softwareverification process.

FIG. 5 is another representation of the gaming software verificationprocess.

FIG. 6 illustrates a smart card and mass storage device interfacing witha main microcontroller board (MMB).

FIG. 7 illustrates the use of a smart card connected to each board in agaming machine to provide secure communications between boards.

FIG. 8 illustrates the different data types stored on the mass storagedevice (e.g., a CD or hard disc).

FIG. 9 illustrates the communication protocol between boards.

FIG. 10 illustrates the exchange of the encryption and decryption keysbetween the smart cards and multiple boards to provide securecommunication between boards.

FIG. 11 illustrates the basic functional units of a securemicrocontroller board in a gaming machine that prevents copying of thegame software and prevents the external reading of any secure data.

FIG. 12 illustrates an example of a metal meander trace that runs over asecure cover overlying the secure area on the controller board, wherebycutting the delicate trace to gain access to the secure area breaks acircuit and causes the secure memories to be erased.

FIG. 13 is a side view of the controller board showing the secure areabeing covered by a secure cover.

DETAILED DESCRIPTION

FIG. 1 is a perspective view of a gaming machine 10 that incorporatesthe present invention. Machine 10 includes a display 12 that may be athin film transistor (TFT) display, a liquid crystal display (LCD), acathode ray tube (CRT), or any other type of display. A second display14 provides game data or other information in addition to display 12.

A coin slot 22 accepts coins or tokens in one or more denominations togenerate credits within machine 10 for playing games. A slot 24 for anoptical reader and printer receives machine readable printed tickets andoutputs printed tickets for use in cashless gaming. A bill acceptor 26accepts various denominations of banknotes.

A coin tray 32 receives coins or tokens from a hopper upon a win or uponthe player cashing out.

A card reader slot 34 accepts any of various types of cards, such assmart cards, magnetic strip cards, or other types of cards conveyingmachine readable information. The card reader reads the inserted cardfor player and credit information for cashless gaming. The card readermay also include an optical reader and printer for reading and printingcoded barcodes and other information on a paper ticket.

A keypad 36 accepts player input, such as a personal identificationnumber (PIN) or any other player information. A display 38 above keypad36 displays a menu for instructions and other information and providesvisual feedback of the keys pressed.

Player control buttons 40 include any buttons needed for the play of theparticular game or games offered by machine 10 including, for example, abet button, a repeat bet button, a play two-ways button, a spin reelsbutton, a deal button, hold cards buttons, a draw button, a maximum betbutton, a cash-out button, a display paylines button, a display payouttables button, select icon buttons, and any other suitable button.Buttons 40 may be replaced by a touch screen with virtual buttons.

FIG. 2 is a block diagram of one type of gaming machine 10 that may beconnected in a network and may include the software and hardware tocarry out the present invention. All hardware not specifically discussedmay be conventional.

A communications board 42 may contain conventional circuitry forcoupling the gaming machine 10 to a local area network (LAN) or othertype of network using Ethernet or any other protocol.

The game controller board 44 contains memory and a processor forcarrying out programs stored in the memory. The game controller board 44primarily carries out the game routines.

Peripheral devices/boards communicate with the game controller board 44via a bus. Such peripherals may include a bill validator 45, a coindetector 46, a smart card reader or other type of credit card reader 47,and player control inputs 48 (such as buttons or a touch screen). Anaudio board 49 converts coded signals into analog signals for drivingspeakers. A display controller 50 converts coded signals to pixelsignals for the display 51.

The game controller board contains a CPU, program RAM, and othercircuits for controlling the operation of the gaming machine. Detail ofone type of controller board is described later with respect to FIG. 11.

The controller board 44 has a smart card I/O port for electricallycontacting the power supply pads, clock pad, and serial I/O pad of astandard secure smart card 54 (also referred to herein as a dongle 54),such as one used for banking around the world. Such smart cards areextremely secure and their physical design and operation are dictated byvarious well known ISO standards, incorporated herein by reference. Anoverview of smart cards and their security features are described in thearticles, “An Overview of Smart Card Security,” by Siu-cheung Chan,1997, available on the world wide web athttp://home.hkstar.com/˜alanchan/papers/smartCardSecurity/, and “SmartCard Technology and Security,” available on the world wide web athttp://people.cs.uchicago.edu/˜dinoj/smartcard/security.html. Botharticles are incorporated by reference to illustrate the pervasiveknowledge of smart card security.

FIG. 3 is a simplified front view of a standard smart card (dongle 54).The card itself is plastic. The card has embedded in it a silicon chip58 (shown in dashed outline) containing a microprocessor (e.g., 8 bit)and memory. A printed circuit 60 provides metal pads for input voltage,ground, clock, and serial I/O. A smart card designed in accordance withthe ISO standards is tamperproof, whereby the stored software cannot beread or copied using practical techniques.

Detailed preferred requirements (but not mandatory) of the system arepresented below. A less secure technique may be accomplished without allof the below preferred requirements. A general overview of the preferreddongle 54 capabilities is as follows.

-   -   1. The dongle must be able to store data which is non-readable        and non-copyable by access to its I/O pads.    -   2. The dongle must have sufficient memory to store the various        crypto keys and the response/configuration data.    -   3. The dongle must be able to perform encryption and decryption        functions.    -   4. The dongle must have a secure hash function. (A hash function        performs an algorithm on any length data and generates a fixed        length hash value that is uniquely associated with the original        data. The hash value is typically used to authenticate data.)    -   5. The dongle must not affect or change the normal game program        functions except to possibly delay the program execution or halt        its execution.

In one embodiment, the dongle receives the challenge data from the hostCPU and performs a function on the challenge data. The functionperformed is kept secure in the dongle. The function can be any suitablefunction. The function may be a proprietary or standard crypto algorithmthat uses secret keys to create an encrypted version of the challengedata by, for example, using RSA, AES, 3DES, or Elliptic Curves. Thecrypto keys for the function are stored in the dongle. The host CPU thendecrypts the dongle response using its secret key(s), which are thecounterparts to the secret keys on the dongle, and compares the responseto an expected response. If there is a match, then the host CPU knowsthat the smart card is authentic. The game program then continues itsnormal flow.

FIG. 4 is a flowchart that depicts the basic steps in the gamingsoftware verification process. In step 61, the manufacturer providesgaming software run by a host CPU inside the gaming machine, where thegaming software issues a challenge (data of any length) to the dongleand must receive a proper response (e.g., an encrypted version of thechallenge) in order for the gaming software to carry out the game. Thegame may be a video reel type game played on a slot machine or any othergame.

In step 63, the manufacturer of the gaming machine or an authorizedcustomer inserts a secure dongle into an I/O port of the game controllerboard (or other location) for communicating with the host CPU.Typically, the manufacturer will insert the dongle prior to the machinebeing shipped to the customer. The dongle may also be distributed withthe game software. The dongle is programmed to process a challenge fromthe host CPU and provide a response. Only a particular response willallow the gaming program to continue. The dongle will typically remainin the gaming machine.

In another embodiment, the gaming machines are client machines, and thegame program is carried out on a remote server. In that case, the donglemay be connected internal to the gaming machine for communication withthe server, and/or the dongle may be connected at the server location.

In step 65, prior to a game being played on the gaming machine, the hostCPU issues a challenge for response by the dongle.

In step 67, the dongle responds, and the host CPU determines if theresponse has the expected properties. The response may be an encryptedversion of the challenge using one or more crypto keys programmed intothe dongle. The host CPU then decrypts the response and compares it toan expected response. The expected response may be generated by the CPUusing the same functions used by the dongle. RSA, DES, and 3DES areexamples of suitable encryption/decryption techniques. The publishedstandards for these techniques are incorporated herein by reference. Theencryption and decryption may use the same secret key (symmetricalgorithm), or different keys are used for encryption and decryption(asymmetric algorithm). In RSA, the sender encrypts a message using thereceiver's public key, and the receiver decrypts the message using thereceiver's private key. The public key and the private key aremathematically related.

In step 69, if the host CPU determines that the dongle response is theexpected response, the host CPU continues the normal gaming program(step 71), and the player plays the game. If the host CPU determinesthat the dongle response is not the expected response, the host CPUhalts the normal gaming program (step 73), and may then issue an alarmor other indication that the dongle is not certified. This suggests thatthe gaming machine software is not legitimate or that an unauthorizeduser is attempting to run the game software.

FIG. 5 is another way of depicting the process of FIG. 4. In FIG. 5, thegame controller board 44 (the host) carries out the normal program flowuntil it gets to the program instruction to issue a challenge (step 74)to the dongle 54. The dongle 54 then responds (step 76) to the challengewith a message uniquely determined by the secret program/data stored inthe dongle's memory chip. In step 78, the host verifies the response. Ifthe response is not correct, the host determines that there is a donglerequest malfunction (step 80) and may, for example, halt the normalprogram flow. If the response is correct, the host continues the normalprogram flow. There will only be a very slight delay in the normalprogram flow using this technique, so the verification process may beused prior to every game being played.

The dongle challenge/response routine may be carried out during anyportion of the normal program flow.

Certain preferred detailed specifications for one type of dongle areprovided below. The preferred specifications are not required for theinvention.

Detailed Specifications for Dongle Request CP Copy Protection CRPChallenge - Response - Protocol DR Dongle Request GAL Gate/Generic ArrayLogic RNG Random Number Generator DRMF Dongle Request Malfunction

MAC Message Authentication Code

The next section introduces design and implementation details forrealizing copy protection with a secure dongle approach.

The purpose of the design is to have a general basis on how to implementa copy protection scheme with dongles as secure as possible.

1.1 Dongle

The basic requirements for the dongle are that: 1) it is a separatedevice that can communicate with the game controller board; and 2) it isable to store data that is non-readable and non-copy able usingpractical techniques. In this invention dongles are used forestablishing challenge—response—protocols.

The following types of dongles are suitable. The list is classified bysecurity levels in descending order.

1.1.1 Types of Dongles

-   -   Smart Cards or Smart Card Controller Chips        -   This is the state of the art technology for protecting            information. Smart Card manufacturers invest a lot in            protecting their Smart Cards against hardware attacks. It's            the most suitable device for cryptographic applications and            therefore very useful for copy protection.    -   General Purpose Microcontrollers        -   Certain general purpose microcontrollers, such as an 8-bit            microcontroller available from various vendors, may be used            as a dongle. This controller can be locked after programming            and serve therefore as a secure storage media. Additionally,            the controllers have enough computational power to execute            strong cryptographic algorithms.        -   Compared to Smart Cards these controllers are not mainly            designed for cryptographic applications and, as a            consequence, provide less protection against hardware            attacks.    -   Gate/Generic Array Logic (GAL) or Programmable Logic devices        (PLD)        -   A GAL or PLD is a chip where a small electronic circuit can            be programmed by firmware after manufacture. Some GALs            contain a mechanism for locking the content. However, it is            not as secure as other alternatives.    -   Off the shelf solutions, as provided by companies such as        Alladin        1.2 Preferred Requirements of Dongles    -   R1 The dongle should be able to store data, which is        non-readable and non-copyable from the outside.    -   R2 The dongle should provide enough secure storage space to        store at least one asynchronous key pair, at least one        synchronous key, and configuration data.    -   R3 The dongle should have at least one strong asymmetric crypto        function for encryption and digital signature, like RSA or        Elliptic Curves.    -   R4 The dongle should have at least one strong symmetric crypto        function, like AES or 3DES.    -   R5 The dongle should have at least one secure hash function,        like SHA-1 or SHA-256.        1.3 Preferred Requirements of Dongle Requests (DRs)

This section gives a list of general requirements that DRs must fulfil.

-   -   R1 A DR should not perform any “crucial gaming device        functions”.    -   R2 A DR should be able to execute a DR malfunction (e.g. HALT        CONDITION). A HALT CONDITION causes the DR to perform a HALT of        the gaming machine.    -   R3 A DR should not contain self-modifying executable code. That        means, a DR should not generate executable code at runtime that        could be executed by the host processor.    -   R4 A DR should not affect normal program execution, except        execution time. The affected execution time should be as low as        possible for successful DRs. Each DR results in a delay. Some        delays may have an impact on game execution time. If this delay        is accepted or not has to be decided for each type of DR. For        nonsuccessful DRs, where a DR malfunction is called, the above        execution time requirements are not valid.    -   R5 Different types of DRs should be implemented.    -   R6 One set of DRs should use proprietary algorithms.        1.4 Static Dongle Requests

There are two main types of DRs: static DRs and dynamic DRs.

In the static DR, the function, which calculates the response from thechallenge, is exclusively available in the dongle itself. Therefore thisfunction is always secret. Static DRs receive a fixed challenge andreply with a fixed response. The advantage is the simplicity, since theyare easy to implement and fast.

The request procedure for a specific static DR works as the following: x= CONST_CHALLENGE y = CONST_RESPONSE y′= DR (x) if (!verify(y, y′))Malfunction ( ) else continue normal program execution

The values x and y are stored on the host application. y' is the resultof the DR. The values CONST₁₃CHALLENGE and CONST₁₃RESPONSE are onlyplace holders for different challenge response pairs.

DR is a place holder for a specific static DR, which has a specificfunction that calculates the result y'.

The secret function can be a proprietary algorithm or a standardsymmetric algorithm, where the secret key is stored exclusively on thedongle.

The verification function verify generally checks whether y' matches theexpectations or not. A very simple verification function would be, forinstance, a one-to-one compare.

1.5 Dynamic Dongle Requests

Dynamic DRs offer a much higher sample space than static DRs. Fordynamic DRs, both the application and the dongle have to calculate a DRfunction to be able to do the comparison.

Dynamic DRs should have a time-variant parameter which needs to beunpredictable and non-repeating. Typically sources for these values arerandom numbers, timestamps, or sequence numbers. There are good pseudorandom number generators available.

Algorithms for the symmetric encryption can be AES, TripleDES or TEAwith different key lengths.

1.5.1 Dongle Requests Using Symmetric Encryption

In symmetric encryption, the algorithm as well as the used key must beknown from both communication partners, the host application and thedongle. Therefore, different keys should be used for different DRs. Thepseudo code describes the procedure for a DR: x = getRand( ) Challenge y= f_(K),(x) y′= DR(x) Response--------------------------------------------------------------------------------------if (!verify(y, y′)) Verification Malfunction( ) else continue normalprogram execution

A random number is chosen from the system random number generator. TheDR function f_(K),(x) is calculated by the host application and on thedongle. The verification function verify generally checks whether y'matches the expectations or not. A very simple verification functionwould be, for instance, a one-to-one compare.

For symmetric encryption, a block cipher or a stream cipher can be used.

1.5.2 Dongle Requests Using Keyed One-Way Functions

Due to computational limitations or export restrictions, the symmetricencryption function can be replaced by a MAC (Message AuthenticationCode) function. Rather than decrypting and verifying, the results of theMAC functions are compared.

There are generally four types of MAC function available:

-   -   1) MACs based on symmetric block ciphers        -   For verification methods of the dongle contents, MACs based            on block ciphers can be used. One suitable type is a CBC-MAC            based on DES, 3DES or AES.    -   2) MACs based on Hash functions        -   This is simply concatenating a key to the input data of a            hash function.    -   3) Customized MACs        -   Suitable types may be a MMA or MD5-MAC.    -   4) MACs for stream ciphers        -   These MACs are designed for stream ciphers. They can be            implemented by combining the output of a CRC checksum with a            key.

For the purpose of the Dongle Requests approach, 2 or 3 should be used.

1.5.3 Dongle Requests Using Asymmetric Encryption

Challenge-Response Protocols (CRPs) can also use asymmetric encryptionapproaches where secrets do not need to be share by the host applicationand the dongle. In asymmetric encryption, only the public key needs tobe stored in the host application. These are the most secure DRs, butrelatively slow. An asymmetric DR looks like: x = getRand( ) Challenge y= f_(kpub),(x) x′= DR(y) Response--------------------------------------------------------------------------------------if (verify(x, x′)) Verification Malfunction( ) else continue normalprogram execution

In this case x is encrypted with the public key by the host applicationand sent to the dongle. The dongle decrypts y with the private key andsends it back.

The verification function verify generally checks whether y' matches theexpectations or not.

For asymmetric encryption, RSA should be used.

1.6 Dongle Request Malfunction (DRMF)

The Dongle Request Malfunction (DRMF) is a function that is implementedwhen the response of the dongle does not match with the expected one.

DRMF must not influence gaming behaviour, except for a called HALTcondition. There are several types of HALT conditions and also differentmethods to trigger them. For example a HALT condition can be reported tothe user or not. There should be DRMFs with different behaviour in thesystem at the same time. Suitable DRMFs are presented below. Theselection may be influenced by jurisdictional limitations.

The following DRMFs use defined normal exception or operationprocedures:

-   DRMF 1 Triggers a Machine Lock. No message to the user. Machine    reinitialisation is necessary.-   DRMF 2 Same as DRMF 1, except the user gets the information that the    machine is locked.-   DRMF 3 Same as DRMF 1, except that the lock is releasable with    reboot.-   DRMF 4 Same as DRMF 2 except that it is releasable with boot.-   DRMF 5 Reset the machine by hardware reset.-   DRMF 6 Inhibit machine startup.-   DRMF 7 Disable user input.-   DRMF 8 Disable user input, except “cash out”    Preferred Detailed Specifications of Smart Card Dongle    1.7 Electronic Gaming Machine

An Electronic Gaming Machine (EGM) is a gaming device, which has atleast one main microcontroller board (MMB) that contains a processor andcontrols the game and its presentation on the screen. Additionalmicrocontroller boards are optional in the EGM.

This board might have a secure area (SA) that contains at least oneSmart Card Access Key (SCAK) and protects it from being accessed fromthe outside. Thus, the key is assumed to be secure and the possibilityof compromise is minimal.

1.7.1 Smart Card

The smartcard (SC) is attached to the MMB of the EGM and contains thejurisdiction specific Game Key (GK). A smart card may be dedicated toone entity (casino, casino group, etc.) and is permitted to be used onlyby this entity. In another embodiment, each EGM has its own unique smartcard. In another embodiment, each game type has its own unique smartcard. It is not possible to decrypt the application software and run agame on an EGM without a valid smart card.

To achieve the trust relationship between an entity and themanufacturer, the smart card and all information on the smart card mustremain the property of the manufacturer.

1.7.2 Entity

An entity is a customer, a casino, a group of casinos, or anybody wholegitimately buys the EGMs and is allowed to operate them. An entityobtains smartcards from the EGM manufacturer.

Controlling the Entities is a method for the EGM manufacturer toregionalise the control of software distribution.

1.7.3 Application Data

The Application Data comprises all software that runs on an EGM (gamesoftware, operating system, etc.). It is stored on the mass storagedevice (MSD) in the EGM in an encrypted form using a symmetricalgorithm. The GK, which is used for encryption and decryption of theapplication data, differs from jurisdiction to jurisdiction.

For EGMs that rely on a remote application server for carrying out agame, a portion of the Application Data is stored on the MSD of theserver.

1.7.4 Mass Storage Device

The Mass Storage Device (MSD) contains the encrypted application dataand some unencrypted, executable software (e.g., the operating system).This can be, for instance, a hard disk, compact flash card, or a CD-ROM.

1.8 Definition of Keys

This section describes all the different keys that will be used in thesecurity concept.

1.8.1 Smart Card Access Key

Every EGM has at least one Smart Card Access Key (SCAK). This is asymmetric or asymmetric cryptographic key. Using this SCAK the EGM isable to be authenticated by the SC and to establish an authenticated andencrypted connection between itself and the SC. If the SCAK is notavailable or incorrect, the smart card denies access and the EGM doesnot carry out the game.

The SCAK should be stored in a tamper resistant storage device on theEGM. This means that it must not be possible to access or to copy thisSCAK from the EGM in any practical way.

1.8.2 Game Key

The Game Key (GK) is the symmetric key used to decrypt the EGMapplication data. It is unique to each jurisdiction and each game, orunique based on other associations. This separation reduces the impactif a GK is compromised. If it is compromised in one jurisdiction, theintellectual property is still protected in all other jurisdictions.

The Game Key is stored on the SC connected to the Main MicrocontrollerBoard (MMB) and it is used for decryption.

1.8.3 Manufacturer's Private/Public Key Pair

The particular manufacturer's private/public key pair is used toidentify smart cards as that manufacturer's smart cards. The public keyis stored on each SC. The private key is used to sign the public key ofa SC (which is unique for each SC). This signature is used to identifythe particular manufacturer's SC.

The manufacturer's public key is stored immutably on each SC issued bythe manufacturer. Its private key is used to “sign” each public key ofall that manufacturer's secure devices. This makes the key exchangebetween two SCs much easier. If SC “A” wants to authenticate SC “B”, itjust checks the signature of SC “B's” public key. If that key was signedby the manufacturer, SC A knows that SC B was issued by thatmanufacturer and that it can trust SC B.

The usage of this manufacturer's key makes the key handling for thatmanufacturer a lot easier. This is the case because no private keys ofthe SCs except that manufacturer's private key and the entity-specificprivate keys need to be stored in the manufacturer's internalkey-database. It also makes the SCs more generic. No suites of keys needto be stored on the SCs and, thus, each SC works together with eachother identified SC.

The manufacturer's private key is very sensitive, and it must never bemade public. Therefore, this private key must be stored in a secureenvironment (e.g., in a smart card) controlled by the manufacturer. Onlya restricted number of persons are allowed to have access to this key.

Entity Private/Public Key Pair

The entity private/public key pair is used in a mechanism to identify asmartcard as a smartcard dedicated to one entity. It is unique for eachentity. The entity public key is stored immutably on each SC issued bythe manufacturer to an entity. The entity private key is used to createdata (e.g. licenses) issued to an entity and to show the SC that it isallowed to store that data on itself.

The private entity keys are sensitive and must never be made public.Therefore, these private keys must be stored in a secure environment.

1.8.4 Operating System Verification Key

The Operating System Verification Key (OSVK) is like the manufacturer'skey, a private/public RSA key pair. It is used to verify theauthenticity of the Operating System (OS) loader and the OS image on themass storage device at EGM start-up.

Therefore, these two modules are signed by the private OSVK. On EGMstart-up, the signatures of the loader and of the image are verifiedusing the public OSVK. The OSVK public key is stored on eachmanufacturer's EGM. If the signature is correct, it is guaranteed thatthe OS was not changed and can be trusted.

The public OSVK is stored on every EGM. Since it is used to verifysignatures it must be trustworthy and thus be stored in awrite-protected memory area of the system (preferably in the BIOS).Since no signatures can be created with the public OSVK, it does notneed to be read-protected.

The private OSVK key is very sensitive and it must never be made public.Therefore, this private key must be stored in a secure environment(e.g., in a smart card) controlled by the manufacturer. Only arestricted number of persons are allowed to have access to this key.

1.9 Preferred Detailed Description of Architecture of MainMicrocontroller Board (MMB)

There are two main design goals of the security concepts describedherein. The first goal is to prevent anybody from making a 1:1 copy ofthe game software and running it on another EGM. The second goal is toprevent the intellectual property (IP), which is the software and data,from being accessed, copied and/or modified by any attacker.

This section gives an overview of the general security architecture fora single board as well as for a multi-board EGM.

1.9.1 Single Board EGM

The EGM only has a single MMB. The SC is directly connected to the MMBand an authenticated and encrypted connection between these two devicesis established to prevent anybody from listening to the communicationsbetween the MMB and the SC or getting access to sensitive data stored onthe SC, such as the GK.

The SC has cryptographic and PKI (public key infrastructure)capabilities to do encryption and authentication. If the SC is notattached to the MMB the EGM will not run a game. It also holds secretsand other data that are checked during runtime by the game. Thisprevents anybody from running a game without an SC and from making a 1:1copy of the game and running it on another EGM.

The protection of the IP is achieved by storing the application data forthe EGM in an encrypted form on the Mass Storage Device MSD. The key todecrypt it at start-up, the so-called Game Key (GK), is stored on the SCconnected to the MMB.

FIG. 6 shows the architecture of an EGM with a single board. The MMB 84has a Secure Area (SA) to store the SCAK in a protected manner and todetect any possible changes to the BIOS. The SC_(MMB) 86 plugs into asmart card reader connected to or on the MMB 84. The MSD 88 may be aperipheral device attached to the MMB or an embedded device on the MMB.Since the application data on the MSD is encrypted, it is not veryimportant that the MSD itself be secure.

1.9.2 Multi Board EGM

When an additional board is used in the EGM, a third protectionmechanism is applied. That is the encryption of the communicationbetween the MMB and the additional board. The second board may also havea SC, though this SC is optional. If no SC is connected to the secondboard, all the cryptographic and PKI functionality must be implementedin software on that board.

FIG. 7 shows the security design architecture of the EGM when SCs areintegrated on both boards.

For simplicity, this document only shows the process for a two boardEGM. Though, the concept can be expanded to more than two boards.Therefore, the additional board is referred to as “Second Board” 90 andthe (optional) SC 92 attached to this board is called SC_(SB).

Overview of Security Protection and Start-Up Sequence

The below section contains the different protection mechanisms of thesecurity concept including boot security, dongle requests, and furtherruntime protection of the EGM.

1.10 EGM Start-up

The boot process of the EGM can be separated into two different tasks,which will be refined in the further sections:

Operating System (OS) boot sequence

Application start-up sequence

The OS boot sequence deals with the start-up of the OS, whereas theapplication start-up sequence is used to decrypt the application datasoftware and start the game

To start the system the MMB needs to contain two different keys:

-   -   Public OSVK for verification of the OS loader and the OS image        stored on the MSD    -   SCAK: to get access to the SC and read the GK from there

The public OSVK is stored on every EGM. Since it is used to verifysignatures, it must be trustworthy and stored in a write-protectedmemory area of the system (e.g. in the BIOS).

Since no signatures can be created with the public OSVK it does not needto be read protected.

1.10.1 Secure Operating System Boot Sequence

The main job of the OS boot sequence is to guarantee that the OS loaderand the OS image on the MSD were not compromised. To achieve thisverification these two software modules are signed with the privateOSVK. Before they are executed, the signature of each module is checkedusing the public OSVK. The first two steps are executed by the BIOS, thefurther two steps are executed by the OS loader:

-   -   1. BIOS—load OS loader from MSD    -   2. BIOS—check signature of OS loader with the public OSVK and        start the loader    -   3. OS Loader—load OS image from MSD    -   4. OS Loader—check signature of OS image and the        init-applications with public OSVK and start OS image and the        init-applications        1.10.2 Application Start-up Sequence

After the OS has been started, the init-applications take control overthe system. Now the SCAK is used to get access to the SC, read the GKand decrypt the applications. Then the applications are verified and, ifeverything was ok, the game is started.

The application start-up sequence can be separated into 5 differentsteps.

1. Establish an authenticated and secured connection to the SC using theSCAK.

2. Access GK in the SC.

3. Load and decrypt application data.

4. Start applications.

5. Run the game.

1.10.3 Mass-Storage-Device Partitions

As shown in FIG. 8, the MSD can be divided into 3 different sections:

-   -   The OS loader 94: This is the loader for the OS for the MMB,        signed with the private OSVK.    -   The OS image and the init-applications 96: This is the OS image        and the initialization applications for the MMB, signed with the        private OSVK. It provides access to the SC_(MMB).    -   The encrypted applications 98: These are the encrypted        applications for the MMB and for the optional additional boards.        They are decrypted during start-up using the GK that is stored        on SC_(MMB).        1.11 Dongle Requests

During runtime, the MMB needs to check whether the SC_(MMB) is stillconnected. This can be done in various ways, such as:

-   -   Plain commands: The EGM sends plain commands to the SC to see if        it is still there.    -   General dongle requests: Dongle requests have been previously        described.        1.12 Multi Board EGM

When the EGM is a multi board machine, also the communication betweenMMB and the additional boards is encrypted. For simplicity, thisdocument only shows the process for a two board EGM. Though, the conceptcan be extended to more than two boards.

For that case, an encrypted and authenticated connection between the MMBand the additional boards is established at the start-up of the EGM. Asshown in FIG. 7, the connection consists of two separate connections:one from the MMB to the second board called the “down-link”, and onefrom the second board to the MMB called “up-link”. Each of theseconnections is encrypted with a different session key. Alternatively,the same key can be used. The keys are generated randomly andindependently on the boards by the SCs and can be changed duringruntime. If no SC is available on the second board, the “up-link” key isgenerated by the board itself. The encryption/decryption of data sentover this connection can be done in software or on the dongle and not onthe SCs.

The recommended algorithm to be used for this symmetric encryption isthe Advanced Encryption Standard (AES), namely the Rijndael algorithm.

1.12.1 Security Protocol

To achieve this encryption and authentication, security can be either beimplemented within or atop the Network Layer or atop the Transport Layerreferring to the standard ISO/OSI network protocol model. That meansthat it works with a connection oriented as well as a connection lessprotocols.

For the cryptographic tasks during the session key exchange process, SCsare used as the secure cryptographic devices and as a secure storage forthe authentication keys.

An example for implementing a custom secure protocol is shown in FIG. 9,which is self-explanatory. However, protocols such as SSL/TLS or IPSeccould just as easily be used.

The physical connection between the MMB and the second board does notreally matter. This example uses a connection oriented protocol (e.g.TCP/IP) at the Transport Layer, and the Security Protocol is set atopthis layer. It is referred to as Secure Inter Board Communication(SIBC). SIBC contains all the functionality to establish a secureconnection, to do the communication encryption, and to access the smartcard cryptographic functionalities. The protocol stack will be equal onMMB and the second board.

1.12.1.1 Example for Connection Establishment and Key Exchange Protocol

The process of establishing the authenticated encrypted links betweenMMB and the second board applies asymmetric cryptography as a keyexchange mechanism. It is described in the flow diagram of the keyexchange protocol in FIG. 10, which is self-explanatory.

FIG. 10 assumes that there is a smartcard available on the second board.If not, then the cryptographic functions on the second board arecomputed in software.

Since the SCs themselves only have limited functionality most of theprotocol functions are implemented in software. That means that the SCsare only used for the key exchange in the protocol. Only the creation ofsession keys, the verification of the counterpart's signature of thepublic key, and the decryption of the encrypted session keys areperformed on the SCs.

This key exchange protocol can be repeated during the runtime of theEGM. It is recommended to renew the session keys (and exchange themagain with the described Key Exchange Protocol) several times duringruntime to decrease the possibility of somebody listening to the datatraffic.

1.12.1.2 Example for Session Key Generation

The session key for the encrypted link is generated by the SC. In orderto create this key, the SC generates a random number. This number ishashed with an algorithm like SHA-1, preferably again on the SC. Thishash result is the session key, which is sent to the software algorithmon the board to which the SC is connected for link decryption. The keyis also encrypted with the other board's (SC's) public key and sent tothat board for link encryption.

The “data portion” that is encrypted with the public key of thecorresponding SC for key exchange should not only be the session keyitself but also additional (random) data.

The SC is the secure device in the system. It must provide PKIfunctionality as well as symmetric cryptography and secure hashalgorithms. Furthermore, it also must provide secure data storage. Theaccess to the cryptographic functions and the secure data must be onlygranted, if the application on the MMB was authenticated by the SC, byusing the SCAK.

Since the task of the SC is to create a secure link between the twoboards, it must have the ability to create symmetric session keys, andit must provide public key facilities. In order to talk to an SC the EGMneeds to hold a Smart Card Access Key (SCAK). This prevents unauthorizedpersonal from misusing an SC. It is also possible to create the sessionkey on the Host.

Continuous checks are done during runtime if the SC_(MMB) is stillconnected to the EGM. If the SC_(MMB) is missing, the EGM cannotoperate, as it cannot decrypt the application data. In a multi board EGMthe encrypted link between the MMB and the second board cannot beestablished without the SC.

1.13 Smartcard (SC) on the MMB

A SC, which is referred to in the following as SC_(MMB), will beattached to every EGM. It holds essential data for decrypting the gameat start-up (the GK), for establishing a secure link between MMB andsecondary boards on a multi board EGM, and for runtime protection, andholds additional data. In order to talk to SC_(MMB), each EGM needs tohave an SCAK. With that key an authenticated and encrypted connectioncan be established between SC_(MMB) and EGM. This prohibits anunauthorized person or machine from reading the GK out of the SC_(MMB).

1.13.1 Contents of SC_(MMB)

The SC_(MMB) contains

-   -   IDs of the entity (casino, casino group, etc.) and IDs of the        jurisdiction    -   A private/public key pairs    -   Signatures for the public key. These signatures are created with        the manufacturer's private keys.    -   The manufacturer's public keys    -   Entity specific public key to authenticate data that will be        stored on the EGM (e.g. GK, license, etc.)—optional.    -   The Game Keys for the game    -   Dongle Request Secrets

The entity ID and the jurisdiction ID show, which entity in whichjurisdiction is allowed to use the SC.

Private/public key pairs are unique for each security device. This keypair is generated on the SC at initialisation (this process is called“personalization”), and the private key must never leave the SC. Thepublic key is also stored in a database controlled by the manufacturertogether with the serial number of the SC. This public key is signed bythe manufacturer's private key. This signature is the proof to identifythe SC to other SCs as the EGM manufacturer's device.

The signature of the public key is a hash value of the SC's public keyencrypted with the private key. It is used to identify themanufacturer's SC_(MMB) to another SC by the same manufacturer.

The manufacturer's public key is used to authenticate another device bythe manufacturer. As was described above (about the establishment of asecure connection between MMB and a second board), SC “A” sends itssigned public key to SC “B”. SC B checks this signature by using thepublic key. If the signature is valid, SC A knows that SC B is thatmanufacturer's device.

The “entity specific public key” allows the SC to check whether alicense or additional data that should be copied onto the card is validor not. Furthermore, this key is unique for each entity (casino, casinogroup, etc.). So if a license is issued it is only valid for one entity.If an entity sells an EGM to another entity they would need to contactthe EGM manufacturer for a new SC. This helps to control the flow ofmachines and software. This key is optional and only necessary when anin-the-field licensing update is implemented.

The GK is used to decrypt the applications and the game at start-up.

The secrets and additional data can be used for so called donglerequests. With these secrets, the SC_(MMB) is able to prove to theapplication that it is really the SC it is supposed to be.

SC_(MMB) is a removable device. That makes it very easy to take a gamefrom one EGM to another one. Only the SC, which fits a game, needs to betransferred to operate the game on the other EGM, providing the targetEGM has the MSD with the game software package inserted.

1.13.2 Requirements for SC_(MMB)

The SC must confirm to some hardware and software requirements. Most ofthem are concerning cryptography and secure storage of data.

Storage

The SC must provide

Non-volatile memory for entity ID and jurisdiction ID

Secure storage for asymmetric keys, e.g., RSA

Secure storage for GK (extendable to license data)

Secure storage for SCAKs

Secure storage for Dongle Request Secrets (such as keys or secretvalues)

Cryptography

The SC must be able to

-   -   Create a private/public key pair. The private key must never        leave the SC.    -   Decrypt data with the private key.    -   Encrypt data with public keys.    -   Store external public keys and use them for encryption of data        and signature verification.    -   Creation of digital signatures    -   Create symmetric session keys (e.g. AES, 3DES,) and return to        the host application.    -   Create random numbers (for key creation).    -   Provide symmetric algorithms for en/decryption of external data.

Functional Requirements

The SC must be able to

-   -   Establish an authenticated and secure communication channel to        the MMB.        1.14 Smart Card on a Second Board

If no SC is connected to a second board, all algorithms and key storagemechanisms must be implemented in software. That means that the secondboard always behaves as if a SC would be connected to it.

In the following, the SC on the second board is referred to as SC_(SB).

1.14.1 Contents of SC_(SB)

The SC_(SB) contains

-   -   Private/public key pairs for inter-board authentication    -   Signatures for the public keys. This signature is created with        the manufacturer's private keys.    -   The manufacturer's public keys

If the SC_(SB) is not part of the EGM, the private/public key pair forinter-board authentication and the public key must be integrated in thesoftware of the second board. This ensures that the operation of the MMBis exactly the same regardless of the presence of an SC_(SB)

The private/public key, the signatures for the public key, and thepublic key have the same meanings as on the SC_(MMB).

SC_(SB) is a removable device.

1.14.2 Requirements for SC_(SB)

The requirements for SC_(SB) are quite similar to that of SC_(MMB).Though, SC_(SB) does not need to store the GK or license data.

Storage

The SC must provide

-   -   Secure storage for asymmetric keys, e.g., RSA    -   Secure storage for a network certificate        Cryptography

The SC must be able to

-   -   Create a private/public key pair. The private key must never        leave the SC.    -   Decrypt data with the private key.    -   Store external public keys and use them for encryption of data        and signature verification.    -   Create symmetric session keys (e.g. AES, 3DES . . . ) and give        it back to the host application.    -   Create random numbers (for key creation).        Preferred Detailed Specification of Smart Card Generation        1.15 Smart Card Generation

The creation of an SC can be separated into three different phases:

Physical generation of the card

Software upload

Personalization

The physical generation of the card is done by the card manufacturer.

The operating system and the application software are loaded onto theSC. Depending on the type of card this upload is performed by the SCmanufacturer or the gaming machine manufacturer.

In the personalization phase, all necessary data such as keys, hashvalues, entity ID etc. are brought onto the card. This phase will takeplace at the EGM manufacturer's facility. It also includes thegeneration of unique private/public key pairs on the card and thesigning of these public keys. The public keys of the card are thenstored together with the cards serial number in the EGM manufacturer'sKey Database

1.16 Manufacturer Databases

To keep track of the different keys that will be used in the securitysystem, and automate the issuing of SCs, databases need to be created.These databases will merely contain public keys (the public keys of thesmart cards), the symmetric GKs, and the serial number or ID of the SC.

1.16.1 Public Keys of MMB Smart Cards

Every SC contains a unique private/public key pair used to identifyitself to other smart cards by the EGM manufacturer. In order to dothis, the public key of each SC must be signed with the manufacturer'sprivate key. This signature is also stored on the SC.

Furthermore, to keep track of the SCs and to be able to encrypt data(e.g. GK, license, . . . ) for a specific SC, the public key of each SCmust be stored together with the serial number of the device in adatabase controlled by the manufacturer. This is especially important ifa licensing system is implemented to be able to create a license for aspecific SC.

The generation and the registration of these private/public key pairsare called “Personalization”. This personalization process is appliedafter production of the SC and before the device is shipped to acustomer.

1.16.2 Game Keys

It is defined that each game is encrypted with a unique symmetric keyfor each jurisdiction. Therefore, a database that holds all differentGame Keys must be established.

When a new application for a jurisdiction is released, a new GK for thisapplication/jurisdiction is created and stored in the database. Thesoftware package for this jurisdiction is encrypted with this new GK.

1.16.3 Game Database

For each game/application different versions of the encrypted softwarepackages for the different jurisdictions should be available. This isdue to the fact that each jurisdiction has a unique GK for a game. Adatabase to handle these different software versions needs to be createdthat contains a connection between version and GK.

1.17 Game Distribution

As a requirement, an application on an EGM is only able to run if therelevant SC is inserted into the EGM. Thus, a distribution mechanismmust be applied to deliver the software packages together with thematching SCs.

1.18 Terms

Entity customer, casino, or group of casinos

Game Key symmetric key to decrypt the EGM application

Signature hash value encrypted by a private asymmetric key

Signature Verification the encrypted hash value is decrypted with thepublic asymmetric key; the result is compared to a newly computed hashvalue of the signed data. If the hash values are equal the signature iscorrect.

Smart Card Access Key key to access confidential data or functionalityon a smart card

1.19 Abbreviations

-   AES Advanced Encryption Standard-   DES Data Encryption Standard-   EGM Electronic Gaming Machine-   GK Game Key-   IP Intellectual Property-   MMB Main Microcontroller Board-   MSD Mass Storage Device-   OS Operating System-   OSVK Operating System Verification Key-   PKI Public Key Infrastructure-   ROM Read Only Memory-   RSA Rivest, Shamir, Adleman—public key algorithm-   SC Smart Card-   SCAK Smart Card Access Key-   SIBC Secure Inter Board Communication-   TCP Transmission Control Protocol    1.20 Preferred Detailed Specification of Secure Module on    Microcontroller Board

The objective of the section is to specify additional board hardwarerequirements related to copy protection of sensitive informationcontained within a microcontroller board on an Electronic Gaming Machine(EGM).

The goal of the concept from the hardware point of view is to protectthose elements of the board considered to be of high security risk. Thehigh security risk elements will be fully specified in this section. Thearea around the security elements is called Secured Area. The SecuredArea must be fully enclosed. This includes also the implementation of anumber of detection methods to prevent access by unauthorized person tothe area. If any access from the outside is detected, all sensitiveinformation on the board is deleted.

It must be guaranteed that no customized BIOS, Smartcard, OperatingSystem (OS) loader, OS Image or Application can be used to obtainsensitive information from the microcontroller board. The sensitiveinformation is considered to be plain text, such as the game applicationor secret keys, stored in the memory inside the secured area. Thissensitive data might contain keys to decrypt the program, which isexecuted on the board.

The secure module is especially applicable for a smart card softwareprotection system described above.

A set of definitions is made for a better understanding of the overallsecurity concept.

1.21 General Definitions

This section describes general terms referring to the security concept.

1.21.1 Microcontroller Board

As shown in FIG. 11, the Microcontroller Board 84 has a Secure Area (SA)107 containing at least a main processor (CPU) 106 and its chipset 108,main memory (RAM) 110, a Security Processor (SP) 112, and BIOS EPROM113. These components are connected via a BUS system 114. A smart cardreader 116 is attached to the board and may be in its own secure area toprevent someone from easily gaining access to the smart card and datalines. Non-sensitive components, shown as block 117 and battery 118, maybe outside the SA 107.

1.21.2 Secure Area

The Secure Area (SA) 107 protects all sensitive components and datalines on the board. It has a series of sensors that detects any kind ofintrusion. If such an intrusion by an attacker is detected, the SPresets the CPU, deletes sensitive data in the secured area.

1.21.3 Security Processor

The Security Processor (SP) 112 surveys all sensors of the secure area.These sensors are a meander system, light sensors, and temperaturesensors. If an intrusion is detected, it deletes all sensitive data onthe board.

1.21.4 Sensitive Data

Sensitive data are protected against any change from the outside or fromeven being read from the outside. This can be decrypted application dataand secret keys. The sensitive data are stored in the memory inside thesecured area.

This section gives a conceptual overview of the security mechanisms onthe microcontroller board 84.

It is assumed that the game application that will be executed on theboard 84 is stored on an external device (e.g., a CD ROM and drive,compact flash memory, server, etc.) only in encrypted form. Thedecrypted and thus executable application is only available inside thesecure area 107.

Only applications encrypted with the correct key(s) are allowed to beloaded onto the board 84. The decryption is either done by the sensitivedata stored inside the secure area or with the help of a smart card.After a successful authentication and decryption, the application can beexecuted. This has also the effect that no software of an unauthorizedparty, which is not encrypted with the correct key(s), can be executedon the board 84.

The SA's only connection to the outside are the Input/Output (I/O)connectors 119. Via the I/O connectors 119, a mass storage device (FIG.7) and other I/O devices are connected to the board 84 (e.g., inputdevices, display devices, network connection, etc.). The smart cardreader 116, which allows the smart card to be easily inserted andremoved, enables the system to be more flexible in the context of secretkey handling and key exchange. In other embodiments, the smart card ishard-wired-connected to the board 84.

All critical components that hold or transfer sensitive data are placedwithin the SA 107. These are devices such as CPU 106, RAM 110, CPUchipset 108, SP 112, and BIOS EPROM 113. Also all data and addressbusses are within the SA 107.

Also all sensors, which are the light and the temperature sensors, areinside the SA 107 and thus cannot be modified from the outside.

The task of the SP 112 is the surveillance of the detection circuitry122 (e.g., the light, wiring, and temperature sensors). When any of thesensors detects an intrusion, the SP 112 deletes the sensitive datainside the secure area.

The BIOS EPROM 113 is also inside the SA 112. Otherwise it would bepossible for an attacker to replace the BIOS by a harmful one and handover sensitive data to the outside (via the I/O connectors 119), or torun unauthenticated software on the board.

1.22 Definition of the Secure Area

The secure area 107 is a three-dimensional-volume which has a meandertrace system on all sides, a light sensor system, and a temperaturesensor system as detection methods for any possible intrusion. Itcontains all sensitive components of the board. Unencrypted software onthe board is only allowed to be within this SA 107.

Tapping into critical signal lines and component pins, downloading ormodifying content of any of the memory, or taking control over any ofthe secured components must be detected.

If such an intrusion by an attacker is detected, the SP 112 resets theCPU 106, deletes the sensitive data in the secure area. Thus, theattacker has no access to the sensitive data stored on the board.

For simplicity only one secure area is described herein, but more thanone secure area may be on the board. All the connections and data linesbetween the SAs must also be protected.

1.23 Detection Circuitry

The detection circuitry 122 must monitor connectivity and otherparameters of the security system to determine if there was an attemptof unauthorized access to the secure area 107. Its core part is theSecurity Processor (SP) 112.

The SP 112 operates the detection circuitry 122 and surveys all thesensors that are integrated into the secure area 107. If any of thesensors detects an intrusion, the SP 112 activates the deletion phase ofthe SA 107 and thus deletes the sensitive data.

In the deletion phase, two different tasks are computed by the SP 112.The first task is to reset the CPU 106. The second task of the SP 112 isthe deletion of the sensitive data stored in the secure area.

The battery 118 supplies the SP 112 with power when the EGM is switchedoff. It may be placed inside or outside the SA 107.

1.24 Sensors in the Secure Area

At least three different detection sensors are integrated into thesecure area 107. They act independently of each other but are allsurveyed by the SP 112.

Meander system on all sides

Light sensors

Temperature sensor

1.24.1 Meander System—The Cover for the Secure Area

A meander trace system creates the cover of the secure area 107. Thecover creates the SA 107 around the Secured Elements. The meander traceis measured for continuity by the detection circuit (FIG. 11). Thesecure area cover cannot be breached without breaking the meander traceand opening up the meander trace circuit.

Unauthorized access to the secured elements within the area is detected.The SA 107 must be fully enclosed by the meander system. That means thatall sides of the SA 107 are bordered by meander traces.

A meander trace 126, shown in FIG. 12, is created with one trace withminimal width (e.g., 0.2 mm max width) and minimal pitch. Trace 126fills the protected area in a serpentine pattern. Any Printed CircuitBoard (PCB) used must be built in a way to minimize the risk of a falsealarm of the light sensors.

FIG. 13 depicts the general approach to protecting the secure area(s)and should be considered as an example. The blocks 128 representintegrated circuit packages. An electrical connector 129 connects themeander trace to detection circuitry 122.

Protecting the secured elements by a meander system can be done indifferent ways. Possible solutions providing additional security levelsare described below:

1. Use a cover consisting of a PCB 130 with a meander layer 132,including side protection.

2. Flexprint inside the covered area with a cutout for the BIOS and theconnector (including side protection).

3. Use an off-the-shelf cover solution, e.g., GORE solution.

1.24.1.1 Security Cover

SIZE The security cover size will be defined during the layout phase ofthe microcontroller board. The smallest possible size should beachieved.

MATERIAL The material used must prevent fault triggering of the lightsensors.

1.24.1.2 Mounting of the Cover

A mounting bracket is needed for the mechanical assembly of the coverand to prevent-false triggering of the light sensors. The cover ismountable when the microcontroller board is assembled.

1.24.1.3 Programming and Enabling of the SP

The final programming of the SP 112 is done at assembly time. That meansthat the SP is blank after production. Before the cover is assembled,the application is put onto the SP via a programming mechanism. When thecover is closed, the SP starts surveying the detection circuitry 122after a defined time period (which can be in the range of 10 to 20seconds). After this time period the sensitive data are deleted when thecover is re-opened.

1.24.2 Light Sensors

The light sensors are in the secure area 107 to detect an intrusion ifone or all of the other sensors fail.

1.24.3 Temperature Sensors

The temperature within the secure area 107 must not exceed thetemperature defined by the security system. These temperature limits aredefined to assure that the detection system works properly.

1.25 Secured Elements

All elements that are within the secure area are referred to as “securedelements”. A secured element may be a component, a test point or asignal. Connection to a pin, via, or trace of any of the securedelements from the outside of the secured area must be detected.

The following components are considered to be secured elements and mustbe fully enclosed (all sides):

-   BIOS EPROM-   The Security Processor-   All components, test points and signals of the detection circuitry    except the battery.-   Chipset of the CPU-   RAM of the board-   CPU-   I/O chips

The following critical signals are considered to be Secured Elements andmust be fully enclosed:

-   CPU signals    -   Reset signal    -   100% of all data signals to the CPU chipset    -   At least 10% of the rest signals to the CPU chipset-   CPU chipset signals    -   Communication signals to the SP    -   At least 10% of all RAM address signals    -   100% of all RAM data signals-   RAM signals    -   At least 10% of all RAM address signals    -   100% of all RAM data signals-   All further bus signals on the microcontroller board

All uses of the word “must” when describing a function are for apreferred embodiment only. In less secure systems, most functions andrequirements described with respect to the preferred system areoptional.

Having described the invention in detail, those skilled in the art willappreciate that, given the present disclosure, modifications may be madeto the invention without departing from the spirit and inventiveconcepts described herein. Therefore, it is not intended that the scopeof the invention be limited to the specific embodiments illustrated anddescribed.

1. A method of providing secure communications in a gaming machinecomprising: providing an authorized first circuit for connection withinthe gaming machine, the first circuit being a modular secure circuitwhereby data stored in the first circuit is protected by securityfeatures, the first circuit containing at least one key for use in acryptographic function; providing a main controller board in the gamingmachine containing a processor and a memory circuit for carrying out agame program; using the at least one key in the first circuit fordecrypting data generated in the gaming machine; carrying out the gameprogram to play a game on the gaming machine if the at least one keystored in the first circuit is a proper key; and preventing carrying outof the game program if it is detected that the first circuit does notcontain the proper at least one key.
 2. The method of claim 1 furthercomprising: providing a secure area on the main controller boardprotected by at least one security feature; and erasing data in thememory circuit upon detection of unauthorized tampering with the securearea.
 3. The method of claim 1 wherein the first circuit is a smartcard.
 4. The method of claim 1 wherein the gaming machine is one of aplurality of machines that use an identical first circuit forcontrolling unauthorized uses of game software.
 5. The method of claim 4wherein the plurality of gaming machines all play the same game.
 6. Themethod of claim 4 wherein the plurality of gaming machines are all usedin a same casino.
 7. The method of claim 4 wherein the plurality ofgaming machines are all used in a same jurisdiction.
 8. The method ofclaim 1: wherein the first circuit contains at least one gamecryptographic key, and wherein carrying out the game program to play agame on the gaming machine comprises using the at least one gamecryptographic key to decrypt a game applications program stored in amemory device in the gaming machine; and wherein the first circuitcontains at least one communications cryptographic key, wherein usingthe at least one key in the first circuit for decrypting data generatedin the gaming machine comprises the first circuit using the at least onecommunications cryptographic key for decrypting communications betweenthe first circuit and the processor on the main processing board.
 9. Themethod of claim 1 wherein the gaming machine contains a second boardhaving a second circuit, the second circuit being a modular, securecircuit containing at least one key for use in a cryptographic function,the method further comprising using the keys in the first circuit andthe second circuit to provide encrypted communications between the maincontroller board and the second board.
 10. The method of claim 1 whereinthe main controller board has a secure access area containing a firstcircuit access key, the method further comprising using the firstcircuit access key in a cryptographic function for providing securecommunications between the main controller and the first circuit. 11.The method of claim 1 wherein the memory on the main controller boardstores an access key to determine the authenticity of the first circuit,and wherein the first circuit contains at least one game cryptographickey, the method further comprising: determining, by communicationsbetween the main controller board and the first circuit, if the accesskey is proper, and, if not, preventing the carrying out of the game;downloading the at least one game cryptographic key from the firstcircuit to the main controller board; decrypting, by the main controllerboard using the at least one game cryptographic key, a game applicationsprogram stored in a memory device in the gaming machine to carry out thegame if it is determined that the access key is proper.
 12. The methodof claim 11 further comprising using the at least one key stored in thefirst circuit for providing encrypted communications between the firstcircuit and the main controller board.
 13. The method of claim 1 whereinthe at least one key in the first circuit comprises a private/public keypair for secure communications and a game key for decrypting a gameapplication program.
 14. The method of claim 1 further comprising:generating a challenge code by the main controller board prior to a gamebeing performed by the gaming machine, the challenge code being fordetermining if the first circuit is an authorized first circuit;receiving the challenge code by the first circuit; generating a responsecode by the first circuit in response to the challenge code; determiningby the main controller board if the response code was a proper responsecode; if the response code was determined to be a proper response code,then determining that the first circuit is an authorized first circuitand carrying out the game program; and if the response code wasdetermined to not be a proper response code, then determining that thefirst circuit is not an authorized first circuit and preventing the gamebeing performed by the gaming machine.
 15. The method of claim 14wherein the first circuit is a smart card.
 16. The method of claim 14wherein the response code is an encrypted version of the challenge code.17. The method of claim 14 wherein the first circuit is a removablecircuit.
 18. A gaming machine for carrying out a game and granting anaward to a player for one or more particular outcomes comprising: afirst controller board having a host processing system for carrying outa program; a memory for storing the program for carrying out a game onthe gaming machine; and a modular, secure first circuit in communicationwith the host processing system, the first circuit being a securecircuit whereby data stored in the first circuit is protected bysecurity features, the first circuit containing at least one key for usein a cryptographic function; the host processing system for carrying outthe program to play a game on the gaming machine if the at least one keystored in the first circuit is a proper key and for preventing carryingout of the game program if it is detected that the at least one keystored in the first circuit is not a proper key.
 19. The machine ofclaim 18 wherein the first circuit contains a processor that uses the atleast one key for encrypting communications between the host processingsystem and the first circuit, and wherein the host processing systemuses the at least one key in the first circuit to decrypt a game programfor carrying out the game.
 20. The machine of claim 18 furthercomprising a second controller board having electrically connected to ita modular, secure second circuit containing at least one key used in acryptographic function to provide secure communications between thefirst controller board and the second controller board.
 21. The machineof claim 18 further comprising: a secure area on the first controllerboard protected by at least one security feature such that triggeringthe at least one security feature erases data in a protected memory onthe first controller board.
 22. The machine of claim 18 wherein thefirst circuit is a smart card.
 23. A method of preventing unauthorizeduse of gaming software in gaming machines comprising: providing anauthorized first circuit for connection within a gaming machine, thefirst circuit being a modular secure circuit whereby data stored in thefirst circuit is protected by security features, the first circuit forcommunicating with a host processing system internal to the gamingmachine to establish that the first circuit is an authorized firstcircuit; providing gaming software in the gaming machine, run by thehost processing system, for carrying out a game played by the gamingmachine, the gaming software preventing carrying out of the game unlessthe authorized first circuit is installed in the gaming machine; andcontrolling distribution of the authorized first circuit such that agaming machine running an unauthorized copy of the game program will notbe able to carry out the game without an authorized first circuit. 24.The method of claim 23 wherein the first circuit is a smart card.